普通安全架构转型微服务安全架构的技术有哪些

普通安全架构转型微服务安全架构的技术有以下这些：

• 共享库：如果两个服务想要共用一些代码，那么这些代码就可以被提取并放到一个共享库中。共享库体现的是一种代码复用思想，公共代码从某一个服务移到共享库就可以被其他服务所使用。共享库实施过程中的主要挑战在于如何判断某些代码应该移到共享库而不是放在本地服务中。微服务架构实际上并不是非常关注代码复用，因为代码复用会导致服务与服务之间产生新的依赖。

• 共享服务：共享服务的思路与共享库类似，只不过在共享服务中，被提取的代码并不是放到一个独立的公共库中，而是直接转移给了另一个服务。与共享库相比，共享服务的优势在于不用产生新的依赖关系，因为服务与服务之间的交互方式并没有任何改变，而服务内部的任何调整并不会产生架构上的影响。共享服务是保持服务大小合理性的一种手段，借助共享服务机制，我们可以对规模比较大的服务进行“瘦身”。

• 代码转移：从一个微服务中抽取一部分代码放到另一个微服务中的做法称为代码转移。通常，我们进行代码转移的主要目的是为了降低两个微服务之间的耦合，提高单个服务的内聚度。当一个微服务需要依赖另一个微服务完成某个功能时，我们认为两者具有一定耦合度，当把两者之间的交互部分代码进行转移之后，这种耦合度就能得到缓解。

• 代码冗余：与其把代码转移到另一个微服务，有时候我们也会选择代码冗余的方式降低服务与服务之间的耦合度。在主流的方法论中，普遍认为代码冗余是一项反模式，因为当代码被冗余在两个地方时，一旦有问题就需要同时修正这两个地方。这是一个架构腐化的危险信号，所以我们一般都尽量避免重复代码的产生。但在微服务架构中，代码冗余有一个非常明显的优势，即两个微服务之间能够保证高度的独立性，从而实现微服务架构所提倡的独立部署。

• 提取新服务：提取新服务具有与共享服务同样的优点和缺点，但是两者具有不同的初衷。当一个服务的规模逐渐增大，提取新服务的目的在于通过减小服务的规模从而降低服务的维护成本，或者把该服务所承载的一部分职责转移到另一个团队。这时候，这个新服务就不会像共享服务那样被多个服务所共同依赖。

• 重写服务：相较其他的架构设计方法，微服务架构中的重写并不是一件非常困难的事情，因为微服务的规模较小，同时具备明确的服务契约。我们有时候会鼓励重写服务，一方面可能来自于技术体系的发展和演进，使用新技术重写一个老服务会带来更好的发展前景。另一个更重要的方面，重写服务驱使我们再次审视服务背后的领域模型，从而为该领域模型提供一种崭新的、更好的实现。